SEP 2 -- 系统健康监控

Head

• Author: larry
• Status: final
• Type: Standards
• Created: 2017-07-14

摘要

提出系统健康监控的几个思路和想法。

动机

近期有部分客户提出我们系统不稳定，速度慢。连续出过几次性能异常事故后，我们产品在客户心中的口碑有很大的打击，有部分客户已经表示对我们系统没信心。我们需要对系统健康状况有明确的感知，需要实时或者准实时的知道系统当前的健康现状，以便有针对性的提高系统可用性。

系统性能监控

全站访问性能

全站访问性能着重从用户端角度考察性能，也就是从浏览器侧度量性能，这个指标直接影响用户体验。主要采用第三方的测试平台来测试，类似拨测之类的。

这里的性能关注两方面：

• 静态资源访问性能

• 接口访问性能

  一般第三方平台无法理解业务，很难正确的测试接口的性能，所以这里可以考虑专门为测试实现一些接口。接口中模拟一些简单的场景，包含一些简单的db查询，然后就可以返回了。

  在每个对外模块中都实现一个这样的接口，已确保每个对外服务模块都能被测试到。

后端系统性能

从请求进入后端机器后开始统计的性能，便于统计优化。

• 接口访问性能，单个接口维度

  • 请求个数
  • 平均时长
  • 最长时长：需要记录发生的时间点，以及对应的请求参数，方便后续排查问题。

• DB查询性能

  主要是慢查询，mongo，mysql。

性能报告

每日发昨日数据的统计报告。

• 接口性能报告：多维度统计

  • 平均时长排序，前10条。
  • 最长时间排序，前10条。
  • 请求个数排序，前10条。

• DB性能报告：慢查询报告。

异常报警

异常报警包含两种

• 接口异常报警：目前因为没接入实时监控系统，暂时还无法做太完善的异常报警，建议把所有模块exception发报警邮件先做起来。
• 系统资源异常报警：配置腾讯云上的资源异常报警，目前应该已经配置了，需要check以下。

系统报错监控

http非200错误

拉取ngnix日志，所有的http非2xx返回都可能是异常，需要逐个分析。

业务代码exception

业务代码的所有exception都需要分析。

业务代码非0返回

业务代码的非0返回，有些是正常的业务流程，有些确实是系统出错，这里可能需要提前做好一些配置能力，能够根据接口和错误码过滤掉一些合理的报错。

报错报告

所有上面的问题都需要放入报告中。